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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The present document is part 2 of a multi-part TS covering the 3 rd Generation Partnership Project: Technical 
Specification Group Services and System Aspects, as identified below: 

Part 1: "3G Fault Management Requirements"; 

Part 2: "Alarm Integration Reference Point: Information Service"; 

Part 3: "Alarm Integration Reference Point: CORBA Solution Set Version 1:1; 

Part 4: "Alarm Integration Reference Point: CMIP Solution Set". 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The present document is part of a set of TSs which describe the requirements and information model necessary for the 
Telecommunication Management (TM) of 3G systems. The TM principles and TM architecture are specified in 
3G TS 32.101 [12] and 3G TS 32.102 [13]. 

A 3G system is composed of a multitude of Network Elements (NE) of various types and, typically, different vendors 
inter-operate in a co-ordinated manner in order to satisfy the network users' communication requirements. 
The occurrence of failures in a NE may cause a deterioration of this NE's function and/or service quality and will, in 
severe cases, lead to the complete unavailability of the NE. In order to minimise the effects of such failures on the 
Quality Of Service (QOS) as perceived by the network users it is necessary to: 

detect failures in the network as soon as they occur and alert the operating personnel as fast as possible; 

isolate the failures (autonomously or through operator intervention), i.e. switch off faulty units and, if applicable, 
limit the effect of the failure as much as possible by reconfiguration of the faulty NE/adjacent NEs; 

if necessary, determine the cause of the failure using diagnosis and test routines; and, 

- repair/eliminate failures in due time through the application of maintenance procedures. 

This aspect of the management environment is termed "Fault Management" (FM). The purpose of FM is to detect 
failures as soon as they occur and to limit their effects on the network Quality of Service (QOS) as far as possible. 
The latter is achieved by bringing additional/redundant equipment into operation, reconfiguring existing 
equipment/NEs, or by repairing/eliminating the cause of the failure. 
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Fault Management (FM) encompasses all of the above functionalities except commissioning/decommissioning of NEs 

and potential operator triggered reconfiguration (these are a matter of Configuration Management (CM), cf. 

3GTS 32.106 [1]). 

FM also includes associated features in the Operations System (OS), such as the administration of a pending alarms list, 

the presentation of operational state information of physical and logical devices/resources/functions, and the provision 

and analysis of the alarm and state history of the network. 
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1 Scope 



The present document (3G TS 32. 1 1 1 Part-2) defines the Alarm Integration Reference Point (IRP) Information Service 
(IS), which addresses the alarm surveillance aspects of Fault Management (FM), applied to the N Interface between 
EM-NM and NE-NM. 

The purpose of the Alarm IRP is to define an interface through which a "system" (typically a Network Element 
Manager or a Network Element) can communicate alarm information for its managed objects to one or several Manager 
Systems (typically Network Management Systems). 

The Alarm IRP IS defines the semantics of alarms and the interactions visible across the reference point in a protocol 
neutral way. It defines the semantics of the operations and notifications visible in the IRP. It does not define the syntax 
or encoding of the operations, notifications and their parameters. 



References 



The following documents contain provisions, which through reference in this text constitute provisions of the present 
document. References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 



• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 
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Definitions and abbreviations 



3.1 Definitions 



In addition to the terms and definitions defined in 3G TS 32.1 1 1-1 [15], the following definitions apply to this 
document: 

Acknowledge alarm: It is functionality provided to facilitate the management of alarms. The definition of the practical 
activity associated to the alarm acknowledgement is outside the scope of this IRP. The alarm acknowledgement process 
is summarised as follows: 

IRP Agent, when first reports an alarm to IRPManager, will set the alarm's Acknowledgement State to 
unacknowledged. IRPManager, on behalf of the user (e.g. operator), can set the state to acknowledged by 
supplying (a) identifier of user acknowledging the alarm and (b) identifier of management system on which 
IRPManager runs. IRP Agent records the two pieces of information and the time of acknowledgement in Alarm 
Information of Alarm List. IRPManager representing a human operator can initiate acknowledge alarm request. 
IRPManager, representing an authorized management application, can initiate acknowledge alarm request as well. 

Alarm List: It contains a list of Alarm Information whose severity level is not Cleared, or severity level is Cleared 
but is not yet Acknowledged. IRP Agent maintains the Alarm List. 

Correlated Notifications: It contains a set of Notification identifiers. It may be present as a parameter of Notification. 
If present, the set of Notifications identified by Correlated Notifications and the subject Notification are related 
(correlated). 

Event: It is an occurrence that is of significance to network operators, the NEs under surveillance and Network 
Management applications. Events do not have state. 

IRPManager: defined in 3G TS 32.102 [13]. 

Notification: It refers to the transport of events from IRP Agent to IRPManager. In this IRP, notification is used to 
carry alarm information from IRP Agent to IRPManager. 

Notification Identifier: It provides an identifier for the notification, which may be carried in the Correlated 
Notifications parameter (see below) of future notifications. Notification identifiers shall be chosen to be unique across 
all notifications of a particular managed object (representing the NE) throughout the time that correlation is significant. 
Notification carries this identifier in parameter called notification Id. The algorithm by which correlation is 
accomplished is outside the scope of this IRP. 

IRPAgent: defined in 3G TS 32.102 [13]. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AIR Alarm Information Reference 

CCITT The International Telegraph and Telephone Consultative Committee 

CMIP Common Management Information Protocol 

EM Element Manager 

IRP Integration Reference Point 

ITU-T International Telecommunication Union, Telecommunication Sector 

M Mandatory 

MO Managed Object 

MOC Managed Object Class 

MOI Managed Object Instance 

NE Network Element 

NM Network Manager 

NMC Network Management Centre 

O Optional 
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OS 
OSI 

ss 

UML 



Operations System 

Open System Interconnection 

Solution Set 

Unified Modeling Language 



4 Basic aspects 
4.1 Background 

Integration Reference Points (IRPs) are the means within 3G Telecom Management (TM) for specifying interoperable 
points of information exchange between systems and applications. 

3G TS 32.101 [12] and 32.102 [13] contain background and introductory information about IRP. 



4.2 System Overview 



The following figures identify system contexts of this IRP in terms of implementations called IRP Agent and 
IRPManager. 

"IRPManager" depicts a process that interacts with IRP Agent for the purpose of receiving alarms via this IRP. 

Examples of IRPManagers can be Network Management Systems and Alarm viewing devices (such as a local craft 

terminal). IRP Agent implements and supports the Alarm IRP. 

IRP Agent can be one Network Element (NE) (see figure 1) or it can be one Element Manager (EM) with one or more 

NEs (see figure 2). In the latter case, the interfaces (represented by a thick dotted line) between the EM and the NEs are 

not subject of this IRP. Whether EM and NE share the same hardware system is not relevant to this IRP either. 

By observing the interaction across the Alarm IRP, one cannot deduce if EM and NE are integrated in a single system 

or if they run in separate systems. 

As indicated in figure 1 and figure 2, the subject IRP need to be complemented with the Notification IRP 
3G TS 32. 106-2 [11] (to allow IRPManager to subscribe to notifications issued by IRP Agent) and (optionally) product- 
specific resource models describing the MOs maintained by IRP Agent. 



IRPManager 



NM 



IRPAgent 





NEs 



Itf-N 




EM 

Notification IRP 
Alarm IRP 



Figure 1 : System Context A 
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Figure 2: System Context B 
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5.1 



IRP Information Service 



Interfaces 



Figure 3 illustrates the operations and notifications defined as interfaces implemented and used by IRP Agent and 
IRPManager. In this document the word "interface" is used to convey identical meaning as that defined within UML. 
Parameters and return status are not indicated. 

Two interfaces are defined. One is called AlarmlRPOperations. This interface defines operations implemented 
by IRP Agent and used (or called by) IRPManager. The other is called AlarmlRPNotif ication. This interface 
defines notification implemented by IRPManager and used by IRP Agent. 



«lnterface» 
AlarmlRPOperations 




|acknowledgeAlarms() 

|unacknowledgeAlarms() 

IgetAlarmListO 

getAlarmlRPVersion() 

getAlarmCountO 



«lnterface» 
AlarmlRPNotifications 




I 



jnotifyNewAlarm() 
jnotifyC hanged Alarm () 
jnotifyAlarmListRebuiltO 
|notifyAckStateChanged() 
jnotifyCleared Alarm () 



Figure 3: Operations and Notification 



5.2 Operations of AlarmlRPOperations Interface 

5.2.1 Operation acknowledgeAlarms (M) 

IRPManager invokes this operation to acknowledge one or more alarms. IRPManager does not supply time of 
acknowledgement. If operation is successful, IRP Agent registers the time of operation in ackTime in Alarm 
Information in Alarm List. IRP Agent registers ackUserld and ackSystemld in Alarm Information. It sets 
ackState to "acknowledged" as well. 

The ackTime, ackUserld, ackSystemld and ackState are collectively called Acknowledgement Information 
in the present document. 

IRP Agent shall send notifications about Acknowledgement Information to all IRPManagers in subscriptions. 
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Tablel : Parameters for acknowledgeAlarms 



Name 


Qualifier 


Purpose 


alarm 

Inf ormationR 

ef erenceList 


Input, M 


It carries one or more identifiers identifying Alarm Information in Alarm List. Each 
identifier identifies at most one Alarm Information in Alarm List. 


AckUserld 


Input, M 


It identities the user acknowledging the alarm. It can be used to identify the human 
operator such as "John Smith" or it can identify a group, such as "Team Six". It may 
contain no information implying that IRPManager does not wish this information be 
kept in Alarm Information in Alarm List. 


ackSystemld 


Input, O 


It identifies the processing system on which the subject IRPManager runs. It may 
contain no information implying that IRPManager does not wish this information be 
kept in Alarm Information in Alarm List. 


badAlarmlnf o 
rmationRef er 
enceList 


Output, M 


It identifies the Alarm Information that are not present in Alarm List or that they are 
present, but Acknowledgement Information has not changed, in contrast to 
IRPManager's request. Element of this list is a pair of Alarm Information Reference 
and reason. This parameter shall contain at least one element in case the output 
status indicates partial failure. Otherwise, it shall contain no information. 


status 


Output, M 


(a) Operation succeeded. Acknowledgement State of all Alarm Information (in 
Alarm List) identified by alarmlnf ormationRef erenceList are 
"acknowledged" or 

(b) Operation failed. No change is made to Acknowledgement Information in any 
Alarm Information in Alarm List. Example of one such failure is when parameter 
alarmlnf ormationRef erenceList contains no identifier or no valid identifier 
or 

(c) Operation partially failed. It indicates that at least one but not all Alarm 
Information (in Alarm List) identified by parameter 

alarmlnformationReferenceList has changed its Acknowledgement 
Information according to IRPManager's request. In this case, the output parameter, 
called badAlarmlnf ormationRef erenceList, shall contain a subset of the 
identifiers carried in parameter alarmlnformationReferenceList. 



5.2.2 Operation unacknowledgeAlarms (O) 

IRPManager invokes this operation to unacknowledge one or more alarms. 

If operation is successful, IRP Agent shall remove all Acknowledgement Information in Alarm Information in Alarm 
List. It shall send notifications carrying Acknowledgement Information to all IRPManagers (including the subject 
IRPManager) in subscriptions. The Acknowledgement Information carried shall contain ackUserld, ackTime and 
ackState. In addition it may contain ackSystemld. 



ETSI 



3G TS 32.111-2 version 3.1.0 Release 1999 



11 



ETSI TS 1 32 1 1 1 -2 V3.1 .0 (2000-07) 



Table 2: Parameters for unacknowledgeAlarms 



Name 


Qualifier 


Purpose 


alarm 

Inf ormationRef e 

renceList 


Input, M 


It carries one or more identifiers identifying Alarm Information in Alarm List. 
Each identifier identifies at most one Alarm Information in Alarm List. 


ackUserld 


Input, M 


It identities the user un-acknowledging the alarm. 


ackSystemld 


Input, O 


It identifies the processing system on which the subject IRPManager runs. 


badAlarmlnf orma 
tionRef erenceLi 

St 


Output, M 


It identifies the Alarm Information that are not present in Alarm List or that they 
are present, but Acknowledgement Information has not changed, in contrast to 
IRPManager's request. Element of this list is a pair of Alarm Information 
Reference and reason. This parameter shall contain at least one element in case 
the output status indicates partial failure. Otherwise, it shall contain no 
information. 


status 


Output, M 


(a) Operation succeeded. Acknowledgement State of the Alarm 
Information (in Alarm List) identified by 

alarmlnf ormationRef erenceList is "unacknowledged" or 

(b) Operation failed. No change is made to Acknowledgement Information in 
any Alarm Information in Alarm List. Failure examples are (a) when parameter 
alarmlnf ormationRef erenceList contains no identifier (b) it contains 
no valid identifier (c) its ackUserld and ackSystemld do not correspond 
to ones used in previous acknowledgeAlarms operation. 

(c) Operation partially failed. It indicates that at least one but not all Alarm 
Information (in Alarm List) identified by parameter 

alarmlnf ormationRef erenceList has changed its Acknowledgement 
Information according to IRPManager's request. In this case, the output 
parameter, called badAlarmlnf ormationRef erenceList, shall contain a 
subset of the identifiers carried in parameter 
alarmlnf ormationRef erenceList. 



5.2.3 Operation getAlarmList (M) 

IRPManager requests IRP Agent to provide a list of alarms in Alarm List. 

Table 3: Parameters of getAlarmList 



Name 


Qualifier 


Purpose 


alarmlnf orm 
ationList 


Output, M 


It carries Alarm Information in Alarm List. Implementation of this parameter is SS 
dependent. 


alarmAckSta 
te 


Input, O 


It has five values indicating a) all alarms b) all active alarms c) all active and 
acknowledged alarms d) all active and un-acknowledged alarms e) all cleared and un- 
acknowledged alarms. 

If present, IRP Agent shall use it to apply on Alarm Information in Alarm List when 
constructing its output parameter alarmlnf ormationList. If input parameter 
filter is also present, the filter constraint carried in filter shall also be applied as 
well. 

If absent, IRP Agent shall return all Alarm Information in Alarm List subject to filter 
constraint expressed in filter parameter. 


filter 


Input, O 


It carries a filter constraint. IRP Agent shall return Alarm Information that satisfy this 

filter constraint only. Filter constraint grammar is SS dependent. 

If parameter is absent and subscriptionldis present and valid, IRP Agent shall 

apply the current filter constraint of the subscription. 

If parameter is absent and subscriptionldis absent, IRP Agent shall return all 

Alarm Information in Alarm List. 


status 


Output, M 


(a) Operation succeeded in that alarmlnf ormationList contains the required 
Alarm Information 

or 

(b) Operation failed because of specified or unspecified reason. 
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5.2.4 Operation getAlarmCount (O) 

IRPManager wishes to know the amount of Alarm Information kept in IRP Agent. IRPManager requests IRP Agent to 
provide the counts via this operation. Possible usage is for IRPManager to find out the number of Alarm Information in 
Alarm List before invoking get AlarmList operation. 

Table 4: Parameters for getAlarmCount 



Name 


Qualifier 


Purpose 


filter 


Input, O 


It carries a filter constraint. IRP Agent shall return Alarm Information that 
satisfy this filter constraint only. Filter constraint grammar is SS dependent. 
If parameter is absent and subscriptionld is present and valid, IRP Agent 
shall apply the current filter constraint of the subscription. 
If parameter is absent and subscriptionld is absent, IRP Agent shall 
return all Alarm Information in Alarm List. 


alarmAckState 


Input, O 


It has five values indicating a) all alarms b) all active alarms c) all active and 
acknowledged alarms d) all active and un-acknowledged alarms e) all cleared 
and un-acknowledged alarms. 

If present, IRP Agent shall apply it for counting. If input parameter filter 
is also present, IRP Agent shall apply the filter constraint for counting as well. 
If absent, IRP Agent shall count all Alarm Information, subject to filter 
constraint expressed in filter parameter. 


criticalCount, 
ma jorCount , 
minorCount , 
warningCount , 
indeterminateCoun 
t, clearedCount 


Output, M 


They specify the number of Alarm Information whose perceived 
severity are critical, major, minor, warning, 
indeterminate and Cleared respectively. 


status 


Output, M 


(a) Operation succeeded in that the counts returned are valid 
or 

(b) Operation failed because of specified or unspecified reason. 



5.2.5 Operation getAlarmlRPVersion (M) 

IRPManager wishes to determine the IRP versions supported by the IRP Agent. IRP Agent shall return with a list of (one 
or more) version numbers currently supported. 

Table 5: Parameters of getAlarmlRPVersion 



Name 


Qualifier 


Purpose 


versionNumbe 
rList 


Output, M 


It indicates one or more SS version numbers supported by the IRP Agent. 


status 


Output, M 


(a) Operation succeeded in that IRP Agent is able to provide the list of version 
numbers. 

(b) Operation failed in that the IRP Agent is not able to provide the list of supported 
version numbers. 



5.3 



Notifications of AlarmiRPNotif ications Interface 



5.3.1 General 

Operations that IRPManager uses to manage subscription to receive notifications are specified in Notification IRP 

(3G TS 32.106-2 [11]). 3G TS 32.106-2 [11] also specifies a generic notification notify. 3G TS 32.106-2 [11] defines 

a number of parameter-attributes that are commonly carried in notifications as well. 

The commonly carried parameter-attributes are collectively called notif icationHeader in the present document. 
The parameter-attribute names and their qualifiers are listed in table 6. 
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Table 6: Notification Header 



Parameter- Attributes defined in 3G TS 32.106-2 [11] 


Qualifier for use in this IS 


managedOb jectClass 


M 


managedOb ject Instance 


M 


not if i cat ion Id 


M 


eventTime 


M 


systemDN 


O 


eventType 


M 


extendedE vent Type 


M 



The following clauses define specific notifications relevant for Alarm IRP by extending notify in 3G TS 32.106-2 
[11]. 

5.3.2 Notification notifyNewAlarm (M) 

IRP Agent notifies the subscribed IRPManager that a new alarm has been added into the 5.4.1 Alarm List and that the 
added alarm satisfies the current filter constraint of the subscription. 

Table 7: Parameters of notifyNewAlarm 



Name 


Qualifier 


Comment 


not if icationHeader 


Input, M 


See Table 6: Notification Header, 


alarmlnf ormationBody 


Input, M 


It contains information about the new alarm. See clause 
4.4.6 Alarm Information. 



5.3.3 Notification notifyChangedAlarm (O) 

IRP Agent notifies subscribed IRPManager regarding changes in e.g. perceived severity level in Alarm Information in 
Alarm List. The Alarm Information carried in the notification shall satisfy the current filter constraint of the 
subscription. 

Table 8: Parameters Of notifyChangedAlarm 



Name 


Qualifier 


Purpose 


not if icationHeader 


Input, M 


See Table 6: Notification Header 


alarmlnf ormationBody 


Input, M 


It contains information of the changed Alarm 
Information. See clause 4.4.6. 



5.3.4 Notification notifyAckStateChanged (M) 

IRP Agent notifies the subscribed IRPManager regarding changes in alarm Acknowledgement State in Alarm 
Information in Alarm List. The Alarm Information carried in the notification shall satisfy the current filter constraint of 
the subscription. 

If the alarm Acknowledgement State is changed to acknowledged, the Acknowledgement Information of the 
Alarm Information in Alarm List shall contain ackTime and ackState indicating "acknowledged". It may contain 
ackUser Id and ackSystemld. The Alarm Information carried in the notification shall contain identical set of 
parameters as well. 

If the Acknowledgement State is changed to "unacknowledged", the Acknowledgement Information of the 
Alarm Information in the Alarm List shall be absent or shall contain no information. The Alarm Information carried in 
the notification shall have the Acknowledgement Information. It shall contain ackUserld, ackTime and 
ackState indicating unacknowledged. It may contain ackSystemld. 
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Table 9: Parameters Of notifyAckStateChanged 



Name 


Qualifier 


Purpose 


not if icationHeader 


Input, M 


See Table 6: Notification Header 


alarmlnf ormationBody 


Input, M 


It contains the Alarm Information whose 

Acknowledgement State has changed. 



Subclause 6.1 specifies the Alarm States and some of these states relate to Acknowledgement State. 

5.3.5 Notification notifyClearedAlarm (M) 

IRP Agent notifies the subscribed IRPManager of alarm clearing if the subject Alarm Information satisfies the optional 
filter constraint expressed in the subscribe operation. 

IRP Agent shall remove the Alarm Information whose perceivedSeverity is cleared and its Acknowledgement 
State is "acknowledged" from Alarm List. 

Table 10: Parameters for notifyClearedAlarm 



Name 


Qualifier 


Purpose 


notification 
Header 


Input, M 


See Table 6: Notification Header 


alarmlnf ormatio 
nBody 


Input, M 


It contains Alarm Information whose perceivedSeverity is 
cleared. Additionally, the Alarm Information may contain 
correlatedNotification (defined in 3G TS 32.106-2 [11]) that 
contains references to other Alarm Information whose 
perceivedSeverity levels are cleared as well. 
Alternatively, it contains an Alarm Information containing a 
correlatedNotification (defined in 3G TS 32.106-2 [11]) that 
contains references to other Alarm Information whose 
perceivedSeverity levels are cleared. 



5.3.6 Notification notifyAlarmListRebuilt (M) 

IRP Agent maintains an Alarm List. If IRP Agent rebuilds this list for any reason, the IRP Agent shall notify 
IRPManager after the Alarm List is rebuilt. The conditions under which IRP Agent shall rebuild and the means by 
which IRP Agent shall rebuild its Alarm List are outside the scope of this IRP. 

Table 11: Parameters for notifyAlarmListRebuilt 



Name 


Qualifier 


Purpose 


notification 
Header 


Input, M 


See Table 6: Notification Header 


reason 


Input, M 


It provides Alarm List rebuilt reason. One valid reason is "indeterminate". 



5.4 



Behaviour 



5.4.1 Alarm List 

IRP Agent maintains an Alarm List. It contains all currently active alarms (i.e. Alarm Information whose 
perceivedSeverity is not Cleared) and alarms that are Cleared but not yet acknowledged. When an alarm is 
Cleared and is acknowledged, its corresponding Alarm Information in this Alarm List is removed. The removed Alarm 
Information shall no longer be accessible via this IRP. 

IRP Agent shall create a new Alarm Information in Alarm List whenever an alarm is emitted (internally within 
IRP Agent) that does not match with any alarm in the Alarm List. In this case, after the creation of the new Alarm 
Information, IRP Agent invokes not if yNewAlarm operation. 
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IRP Agent shall not create a new Alarm Information in Alarm List when an alarm is emitted (internally within 
IRP Agent) that matches with an alarm in the Alarm List. In this case, IRP Agent shall invoke either 

(1) notifyChangedAlarm or (2) not if yClearedAlarm followed by not if yNewAlarm operation. 

See Annex D for specification of alarm matching criterion. 

In the case of a matched Alarm Information and the change is the perceived Severity value, the following additional 
rule shall apply. 

IRP Agent shall remove all information in Acknowledgement Information of the subject Alarm Information. The 
Acknowledgement State shall be "unacknowledged". IRP Agent updates the eventTime and 
perceivedSeverity of the matched Alarm Information. IRP Agent invokes notifyChangedAlarm 
notification to all subscribed IRPManagers. 

5.4.2 Network Resource Name 

An alarm provides the alarm information of a specific network resource. Alarms use one parameter-attribute, Managed 
Object Instance (MOI), to identify the network resource. The semantics of MOI is defined in ITU-T Recommendation 
X.720 [8]. The MOI shall be unique within a certain context, such as a transmission network or a switching network. 
This IRP does not specify the context. 

The encoding of MOI parameter-attribute value is SS dependent and is specified in ITU-T Recommendation X.720 [8] 
and 3GTS 32.106-8 [14]. 

5.4.3 Alarm Information Identification 

Since IRPManager can acknowledge and unacknowledge Alarm Informations currently kept in Alarm List of 

IRP Agent, there is a need to establish a convention so IRPManager and IRP Agent can unambiguously identify Alarm 

Informations in Alarm List. 

Since IRP Agent can generate notifications about the state change (e.g. perceivedSeverity level changes or 
Acknowledgement State changes) of an Alarm Information in Alarm List, there is a need to establish a 
convention so IRPManager and IRP Agent can unambiguously identify the Alarm Information whose state has changed. 

The convention, to identify Alarm Information, is the subject of this clause. 

5.4.3.1 L)SG of alarmlnf ormationRef erence 

An alarmlnf ormationRef erence (AIR) unambiguously identifies one Alarm Information in IRP Agent's Alarm 
List. One IRP Agent has one Alarm List. The IRP Agent assigns AIR for the Alarm Informations in its own Alarm List. 

IRP Agent includes AIR in all notifications it emits. 

IRPManager shall include AIR(s) in acknowledgeAlarms and unacknowledge Alarms. 

The mapping of AIR into its equivalents in respectively SS are done in Annex D. 



5.4.4 Alarm loss detection and recovery 



This IRP does not specify methods for IRPManager to detect alarm loss. The use of alarmld (see clause 4.4.3.1) to 
detect alarm loss is an arrangement made between IRP Agent and IRPManager. This arrangement is outside the scope 
of this IRP. For example, IRP Agent may use integer sequence (e.g. 1, 2, 3, 4, 5...) as alarmlds for its alarms. Based 
on this knowledge, IRPManager can detect alarm loss. This kind of arrangement may not be possible for all SS. 

This IRP does not specify if IRP Agent can determine if IRPManager has received alarms correctly. Not all SSs provide 
such capability. 

This IRP does not specify methods for IRPManager and IRP Agent to recover alarm loss. The only mechanism 
recommended to deal with alarm loss is the use of getAlarmList operation. This IRP does not specify conditions 
under which IRPManager should invoke this operation. 
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5.4.5 Alarm List loss 

IRP Agent can lose confidence in the integrity of its Alarm List. Under this condition, IRP Agent shall invoke 
notifyAlarmListRebuilt notification after it has successfully rebuilt the Alarm List. 

5.4.6 Alarm Information 

This clause specifies the information contained in Alarm Information. 

Alarm Information(s) are stored in Alarm List. They are carried in not if yNewAlarm, not if yChangedAlarm, 
notifyAckStateChanged, notif yClearedAlarm. They are also carried in the response to 
getAlarmList operation. 

When it is carried in not i f yChangedAlarm notification, it indicates that one or more parameter-attribute values of 
the Alarm Information have changed since the most recent notif yNewAlarm or notif yChangedAlarm 
notification on the subject alarm. The following table identifies, using the symbol [Y] under "Qualifier" column, those 
parameters-attributes whose value changes would trigger IRP Agent to invoke notif yChangedAlarm or 

notifyAckStateChanged notification. 

When the alarm is carried in notif yChangedAlarm or notifyAckStateChanged notification, the following 
rule shall apply: 

At least the value of one parameter-attribute marked with [ Y] shall be different than that carried in the most 

recent not if yNewAlarm or notifyChangedAlarm of the subject alarm. 

Alarm Information, carried in notifications, always contain the AIR. In notif yNewAlarm, the AIR is used to 

identify the active Alarm Information carried in the notification. In not i f yChangedAlarm and 

notif yClearedAlarm, the AIR is used to identify the active Alarm Information whose state has changed. 

In notif yAckStateChangedAlarm, the AIR is used to identify the Alarm Information (active or inactive) in the 

Alarm List whose acknowledgement state has changed. 

Alarm Information contains the notif icationHeader and alarmlnf ormationBody. Table 6 defines 
parameter-attributes of notif icationHeader. Table 13 defines the parameter-attributes of 

alarmlnf ormationBody. 

Letter M and O stands for Mandatory and Optional respectively. Letter Y identifies the parameter-attribute whose 
value changes would trigger IRP Agent to invoke notifyChangedAlarm or notifyAckStateChanged. 
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Table 13: Parameter-Attributes of alarminformationBody 



Name 


Qualifier 


Comment 


probable 
Cause 


M 


It qualifies alarm and provides further information than eventType. See Annex B 
for a complete listing. This list is extensive. It is recommended that IRP Agent 
should use the list as is and not to extend it. It is noted that IRP Agent can privately 
(outside the scope of this IRP) define values for specif icProblem that provides 
semantics not conveyed by probableCause. A special probable cause value (SS 
specific, e.g. -1) indicates that this alternative is valid. This parameter-attribute 
value shall be single-value and of simple type such as integer or string. See 
definition in ITU-T Recommendation X.733 [2] clause 8.1.2.1. 


perceived 
Severity 


M, Y 


It indicates the relative level of urgency for operator attention. . Legal values are 

Critical, Major, Minor, Warning, Indeterminate and 
Cleared, according to ITU-T Recommendation X.733 [2]. This IRP does not 
recommend the use of indeterminate. 


specific 
Problem 


O 


It provides further qualification on the alarm than probableCause. This 
parameter-attribute value shall be single-value and of simple type such as integer or 
string. See definition in ITU-T Recommendation X.733 [2] clause 8.1.2.2. 


correlated 
Notifications 


O 


It identifies a set of notifications to which this notification is considered to be 
correlated. See definition in ITU-T Recommendation X.733 [2] clause 8.1.2.9. 


backedUpStatu 
s 


O, Y 


It indicates if an object has a back up. See definition in ITU-T Recommendation 
X.733 [2] clause 8. 1.2.4. 


backUpOb ject 


O, Y 


It carries the DN of the back up object. It shall be absent if backUpStatus is absent 
or its value indicates false. See definition in ITU-T Recommendation X.733 [2] 
clause 8.1.2.5. 


trend 
Indication 


O, Y 


It indicates if some observed condition is getting better, worse, or not changing. 
Legal values are "less severe", "no change" and "more severe". See definition in 
ITU-T Recommendation X.733 [2] clause 8.1.2.6. 


threshold 
Info 


O, Y 


It indicates if the threshold crossed was in the up or down direction. See definition 
in ITU-T Recommendation X.733 [2] clause 8.1.2.7. 


stateChange 

Definition 


O, Y 


It indicates MO attribute value changes. See definition in ITU-T Recommendation 
X.733 [2] clause 8.1.2.10. 


monitored 
Attributes 


O, Y 


It indicates MO attributes whose value changes are being monitored. See definition 
in ITU-T Recommendation X.733 [2] clause 8.1.2.11. 


proposed 

Repair 

Actions 


O, Y 


It indicates proposed repair actions. See definition in ITU-T Recommendation 

X.733 [2] clause 8.1.2.12. 


additional 
Text 


o, 


It provides the identity of the NE (e.g. RNC, Node-B) from which the alarm has 
been originated. It corresponds to the "user label" attribute of the MOC representing 
the NE in the Basic CM IRP Information Model. 
It can contain further information on the alarm. 


additional 
Information 


(see next 
column) 


It carries additional information related to the subject Alarm Information. It may 

contain the following parameter-attributes. 

Alarmld [ Y]: It identifies at most one Alarm Information in the Alarm List. See 

clause 5.4.3.1. Use of this parameter-attribute is SS dependent. 

ackTime [Y]: It identifies the time of last operation acknowledgeAlarms or 

unacknowledgeAlarms. It is mandatory for notif yAckStateChanged, it 

is optional for other notifications. 

ackUserld [Y]: It identifies the last user who has change the 

Acknowledgement State via operation acknowledgeAlarms or 

unacknowledgeAlarms. It is mandatory for notif yAckStateChanged, it 

is optional for other notifications. 

ackSystemld [Y]: It identifies the system in which IRPManager, that invokes the 

acknowledgeAlarms or unacknowledgeAlarms operation, runs. It is 

optional for all notifications. 

ackState [Y]: It identifies the Acknowledgement State of the alarm. Its 

valid values are "acknowledged" and "unacknowledged". It is mandatory for 

notif yAckStateChanged, it is optional for other notifications. 
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Dynamic Model 



6.1 



Alarm states 



Alarms have states. Figure 4 illustrates the alarm states. 

The triggers "MO emits..." are internal within IRP Agent and are not observable via the Alarm IRP. Other triggers, e.g 
"acknowledgeAlarms", are observable via the Alarm IRP. 

The solid circle icon represents the Start State. The double circle icon represents the End State. In this state, 
the alarm is cleared and acknowledged. The alarm shall not be accessible via the IRP and is removed from the Alarm 
List. 



MO emits changed 
alarm 



MO emits [ una ck&unclear 
new alarm 

> 



acknowledgeAlarms 



< 

^ unacknowledgeAlarms 

MO emits changed alarm 



MO emits alarm cleared 



r * 

unack&clear 

V. J 



acknowledgeAlarms 




MO emits alarm cleared 



ack&clear state. Alarm 
Information is no longer 
accessible via this IRP. 



Figure 4: Alarm States 
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Annex A (normative): 

Event Types and Extended Event Types 

This appendix lists and explains event types and extended event types used by Alarm IRP. 

Event type is carried by a parameter called eventType defined in 3G TS 32.106-2 [11], 

Extended event types is acrried by a parameter called extendedEventType 3G TS 32.106-2 [11]. 

Encoding of eventType and extendedEventType is SS dependent. For example, the value of eventType 
can be encoded as Object Identifier in CMIP SS and as numeric string in CORBA SS. 

Table 14 and table 15 may be extended in the future. 

TableA.1 : Event Types 



Event Types 



Explanation 



Communications Alarm 



An alarm of this type is associated with the procedure and/or process required conveying information from 
one point to another (ITU-T Recommendation X.733 [2]). 



Processing Error Alarm 



An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733 [2]). 



Environmental Alarm 



An alarm of this type is associated with a condition related to an enclosure in which the equipment resides 
(ITU-T Recommendation X.733 [2]). 



Quality of Service Alarm 



An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation 
X.733 [2]). 



Equipment Alarm 



An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733 [2]). 



Table A.2: Extended Event Types 



Extended Event Types 


Explanation 


New Alarm 


A notification of this type indicates that a new alarm has occurred. 


Changed Alarm 


A notification of this type indicates that one or more attributes, excepting those related to 
acknowledgement state, of an active alarm have changed. 


Acknowledgement State Changed 


A notification of this type indicates that the acnowledgement state of an alarm has changed. 


Cleared Alarm 


A notification of this type indicates that an alarm has been cleared and is no longer active. 


Alarm List Rebuilt 


A notification of this type indicates that the Alarm List has been succesfully rebuilt. 
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Annex B (normative): 
Probable Causes 



This appendix lists probable causes and their corresponding event types. 

Sources of these probable causes are ITU-T Recommendation M.3100 [9], ITU-T Recommendation X.721 [3], ITU-T 
Recommendation X.733 [2], ITU-T Recommendation X.736 [4] and GSM 12.11 [10]. 

The list may be extended in the future, e.g. with UMTS-specific probable causes. 

Table B.1 : Probable Causes from ITU-T Recommendation M.3100 [9] 



M.3100 Probable cause 


Event type 


Indeterminate 


Unknown 


Alarm Indication Signal (AIS) 


Commun 


cat 


ons 


Call Setup Failure 


Commun 


cat 


ons 


Degraded Signal 


Commun 


cat 


ons 


Far End Receiver Failure (FERF) 


Commun 


cat 


ons 


Framing Error 


Commun 


cat 


ons 


Loss Of Frame (LOF) 


Commun 


cat 


ons 


Loss Of Pointer (LOP) 


Commun 


cat 


ons 


Loss Of Signal (LOS) 


Commun 


cat 


ons 


Payload Type Mismatch 


Commun 


cat 


ons 


Transmission Error 


Commun 


cat 


ons 


Remote Alarm Interface 


Commun 


cat 


ons 


Excessive Bit Error Rate (EBER) 


Commun 


cat 


ons 


Path Trace Mismatch 


Commun 


cat 


ons 


Unavailable 


Commun 


cat 


ons 


Signal Label Mismatch 


Commun 


cat 


ons 


Loss Of Multi Frame 


Commun 


cat 


ons 


Back Plane Failure 


Equipment 


Data Set Problem 


Equipment 


Equipment Identifier Duplication 


Equipment 


External IF Device Problem 


Equipment 


Line Card Problem 


Equipment 


Multiplexer Problem 


Equipment 


NE Identifier Duplication 


Equipment 


Power Problem 


Equipment 


Processor Problem 


Equipment 


Protection Path Failure 


Equipment 


Receiver Failure 


Equipment 


Replaceable Unit Missing 


Equipment 


Replaceable Unit Type Mismatch 


Equipment 


Synchronisation Source Mismatch 


Equipment 


Terminal Problem 


Equipment 


Timing Problem 


Equipment 


Transmitter Failure 


Equipment 


Trunk Card Problem 


Equipment 


Replaceable Unit Problem 


Equipment 


Air Compressor Failure 


Environmental 


Air Conditioning Failure 


Environmental 


Air Dryer Failure 


Environmental 


Battery Discharging 


Environmental 


Battery Failure 


Environmental 


Commercial Power Failure 


Environmental 


Cooling Fan Failure 


Environmental 


Engine Failure 


Environmental 


Fire Detector Failure 


Environmental 


Fuse Failure 


Environmental 


Generator Failure 


Environmental 


Low Battery Threshold 


Environmental 


Pump Failure 


Environmental 
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M.3100 Probable cause 



Event type 



Rectifier Failure 



Environmental 



Rectifier High Voltage 



Environmental 



Rectifier Low F Voltage 



Environmental 



Ventilation System Failure 



Environmental 



Enclosure Door Open 



Environmental 



Explosive Gas 



Environmental 



Fire 



Environmental 



Flood 



Environmental 



High Humidity 



Environmental 



High Temperature 



Environmental 



High Wind 



Environmental 



Ice Build Up 



Environmental 



Intrusion Detection 



Environmental 



Low Fuel 



Environmental 



Low Humidity 



Environmental 



Low Cable Pressure 



Environmental 



Low Temperature 



Environmental 



Low Water 



Environmental 



Smoke 



Environmental 



Toxic Gas 



Environmental 



Storage Capacity Problem 



Processing error 



Memory Mismatch 



Processing error 



Corrupt Data 



Processing error 



Out Of CPU Cycles 



Processing error 



Software Environment Problem 



Processing error 



Software Download Failure 



Processing error 
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Table B.2: Probable Causes from ITU-T Recommendation X.721 [3] / ITU-T Recommendation X.733 [2] 



X.733 Probable Cause 


Event type 


Adapter Error 


Equipment 


Application Subsystem Failure 


Processing error 


Bandwidth Reduction 


Quality of service 


Call Establishment Error 


Communications 


Communication Protocol Error 


Communications 


Communication Subsystem Failure 


Communications 


Configuration or Customizing Error 


Processing error 


Congestion 


Quality of service 


Corrupt Data 


Processing error 


CPU Cycles Limit Exceeded 


Processing error 


Data Set or Modem Error 


Equipment 


Degraded Signal 


Communications 


DTE-DCE Interface Error 


Communications 


Enclosure Door Open 


Environmental 


Equipment Malfunction 


Equipment 


Excessive Vibration 


Environmental 


File Error 


Processing error 


Fire Detected 


Environmental 


Flood Detected 


Environmental 


Framing Error 


Communications 


Heating or Ventilation or Cooling System Problem 


Environmental 


Humidity Unacceptable 


Environmental 


Input/Output Device Error 


Equipment 


Input Device Error 


Equipment 


LAN Error 


Communications 


Leak Detection 


Environmental 


Local Node Transmission Error 


Communications 


Loss of Frame 


Communications 


Loss of Signal 


Communications 


Material Supply Exhausted 


Environmental 


Multiplexer Problem 


Equipment 


Out of Memory 


Processing error 


Output Device Error 


Equipment 


Performance Degraded 


Quality of service 


Power Problem 


Equipment 


Pressure Unacceptable 


Environmental 


Processor Problem 


Equipment 


Pump Failure 


Environmental 


Queue Size Exceeded 


Quality of service 


Receive Failure 


Equipment 


Receiver Failure 


Equipment 


Remote Node Transmission Error 


Communications 


Resource at or Nearing Capacity 


Quality of service 


Response Time Excessive 


Quality of service 


Re-transmission Rate Excessive 


Quality of service 


Software Error 


Processing error 


Software Program Abnormally Terminated 


Processing error 


Software Program Error 


Processing error 


Storage Capacity Problem 


Processing error 


Temperature Unacceptable 


Environmental 


Threshold Crossed 


Quality of service 


Timing Problem 


Equipment 


Toxic Leak Detected 


Environmental 


Transmit Failure 


Equipment 


Transmitter Failure 


Equipment 


Underlying Resource Unavailable 


Processing error 


Version Mismatch 


Processing error 
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Table B.3: Probable Causes from GSM 12.11 [10] 



GSM 12.11 Probable Cause 


Event Type 


A-bis to BTS interface failure 


Equipment 


A-bis to TRX interface failure 


Equipment 


Antenna problem 


Equipment 


Battery breakdown 


Equipment 


Battery charging fault 


Equipment 


Clock synchronisation problem 


Equipment 


Combiner problem 


Equipment 


Disk problem 


Equipment 


Equipment failure 


Equipment 


Excessive receiver temperature 


Equipment 


Excessive transmitter output power 


Equipment 


Excessive transmitter temperature 


Equipment 


Frequency hopping degraded 


Equipment 


Frequency hopping failure 


Equipment 


Frequency redefinition failed 


Equipment 


Line interface failure 


Equipment 


Link failure 


Equipment 


Loss of synchronisation 


Equipment 


Lost redundancy 


Equipment 


Mains breakdown with battery back-up 


Equipment 


Mains breakdown without battery back-up 


Equipment 


Power supply failure 


Equipment 


Receiver antenna fault 


Equipment 


Receiver Failure 


Equipment 


Receiver multicoupler failure 


Equipment 


Reduced transmitter output power 


Equipment 


Signal quality evaluation fault 


Equipment 


Timeslot hardware failure 


Equipment 


Transceiver problem 


Equipment 


Transcoder problem 


Equipment 


Transcoder or rate adapter problem 


Equipment 


Transmitter antenna failure 


Equipment 


Transmitter antenna not adjusted 


Equipment 


Transmitter failure 


Equipment 


Transmitter low voltage or current 


Equipment 


Transmitter off frequency 


Equipment 


Database inconsistency 


Process 


ng error 


File system call unsuccessful 


Process 


ng error 


Input parameter out of range 


Process 


ng error 


Invalid parameter 


Process 


ng error 


Invalid pointer 


Process 


ng error 


Message not expected 


Process 


ng error 


Message not initialised 


Process 


ng error 


Message out of sequence 


Process 


ng error 


System call unsuccessful 


Process 


ng error 


Timeout expired 


Process 


ng error 


Variable out of range 


Process 


ng error 


Watch dog timer expired 


Process 


ng error 


Cooling system failure 


Env 


ronmental 


External equipment failure 


Env 


ronmental 


External power supply failure 


Env 


ronmental 


External transmission device failure 


Env 


ronmental 


Fan failure 


Env 


ronmental 


High humidity 


Env 


ronmental 


High temperature 


Env 


ronmental 


Intrusion detected 


Env 


ronmental 


Low humidity 


Env 


ronmental 


Low temperature 


Env 


ronmental 


Smoke detected 


Env 


ronmental 


Excessive Error Rate 


Quality of service 


Reduced alarm reporting 


Quality of service 


Reduced event reporting 


Quality of service 
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GSM 12.11 Probable Cause 



Event Type 



Reduced logging capability 



Quality of service 



System resources overload 



Quality of service 



Broadcast channel failure 



Communications 



Connection establishment error 



Communications 



Invalid message received 



Communications 



Invalid MSU received 



Communications 



LAPD link protocol failure 



Communications 



Local alarm indication 



Communications 



Remote alarm indication 



Communications 



Routing failure 



Communications 



SS7 protocol failure 



Communications 



Transmission error 



Communications 



Table 20 identifies probable causes that are defined by more than one standard. This is for information only. 

Table B.4: Duplicated Probable Causes 



Duplicated Probable Cause 


GSM 12.11 


X.721 X.733 


M.3100 


Event Type 


Call Establishment Failure (X.721/X.733) 
Call Setup Failure (M.3100) 




X 


X 


Communications 


Degraded Signal 




X 


X 


Communications 


Framing Error 




X 


X 


Communications 


Loss of Frame 




X 


X 


Communications 


Loss of Signal 




X 


X 


Communications 


Equipment Failure (GSM 12.11) 
Equipment Malfunction (X.721/X.733) 


X 


X 




Equipment 


Multiplexer Problem 




X 


X 


Equipment 


Power Problem 




X 


X 


Equipment 


Processor Problem 




X 


X 


Equipment 


Receiver Failure 


X 


X 


X 


Equipment 


Timing Problem 




X 


X 


Equipment 


Transmitter Failure 


X 


X 


X 


Equipment 


Enclosure Door Open 




X 


X 


Environmental 


Fan Failure (GSM 12.11) 
Cooling Fan Failure (M.3100) 


X 




X 


Environmental 


Fire Detected (X.721/X.733) 
Fire (M.3100) 




X 


X 


Environmental 


Flood Detected (X.721/X.733) 
Flood (M.3100) 




X 


X 


Environmental 


High Humidity 


X 




X 


Environmental 


High Temperature 


X 




X 


Environmental 


Intrusion Detected (GSM 12.1 1) 
Intrusion Detection (X.736/M.3100) 


X 




X 


Environmental 


Low Humidity 


X 




X 


Environmental 


Low Temperature 


X 




X 


Environmental 


Pump Failure 




X 


X 


Environmental 


Smoke Detected (GSM 12.11) 
Smoke (M.3100) 


X 




X 


Environmental 


Storage Capacity Problem 




X 


X 


Processing Error 


Excessive Bit Error Rate (M.3 100) 
Excessive Error Rate (GSM 12. 11) 


X 




X 




Corrupt Data 




X 


X 


Processing Error 
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Annex C (informative): 

Examples Use Of notifyChangedAlarm 

This appendix describes a number of valid and invalid interactions governing the case when IRP Agent is reporting a 
specific fault of a particular network resource whose alarm severity level changes from, say critical to minor and then to 
Cleared. 

In the examples, ni is notification Id, moc is managedOb jectClass, moi is managedOb ject Instance, 
et is eventType, pc is probableCause, sp is specif icProblem, ps is perceivedSeverity and ai is 
Alarmld. 

Valid sequence 1 to support the hypothetical case: 

(1) Notify NewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyChangedAlarm 

(ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

(3) NotifyClearedAlarm 

(ni=3, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 
Valid sequence 2 to support the hypothetical case: 

(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyClearedAlarm 

(ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(3) NotifyNewAlarm 

(ni=3, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

(4) NotifyClearedAlarm 

(ni=4, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 
Invalid sequence 1 to support the hypothetical case: 

(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyChangedAlarm 

(ni=2, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

(3) NotifyClearedAlarm 

(ni=3, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 
Interaction (2) is illegal since it uses a different ai for the same alarm. It should use ai=X as in interaction (1). 
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Invalid sequence 2 to support the hypothetical case: 

(1) Notify NewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyNewAlarm 

(ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

Interaction (2) is illegal since it invokes notifyNewAlarm using same ai value. It should use 

notifyChangedAlarm with the same ai value. 
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Annex D (normative): 

Mapping of Alarm Information Reference to its Solution Set 

Equivalents 

This appendix specifies the mapping of AIR into its SS equivalents. It also specifies the conditions under which these 
attributes shall be used in the mapping process. 

Currently, there are two methods to map AIR into SS equivalents. One method is the use of 

managedOb ject Instance and notification Id whose semantics are defined by ITU-T. The other method is 
the use of alarmld whose semantics is identical to AIR. 

Table 21 specifies how identification of Alarm Information is achieved, with and without the use of alarmld. 

Table D.1 : AIR Mapping Process 





Alarmld is used 


Alarmld is not used 


Acknowledg 
eAlarm, 
unacknowle 
dgeAlarm 


IRPManager places value of alarmld of 
the received notif yNewAlarm or 
related notifyChangedAlarm or 
related notifyClearedAlarm (they 
shall have the same value) in AIRs of 
alarml n format ionRef erenceLi st 
of this operation. 
IRPManager can place multiple values. 


IRPManager places values of 

managedOb jectlnstance and 

notif icationld of the received 

not if yNewAlarm notification in AIRs of 

alarmlnf ormat ionRef erenceLi st of this 

operation. 

IRPManager can place multiple pairs of values. 


not if yNewA 
larm 


IRP Agent assignes a new alarmld for this 
notification. 

AIR is mapped to this alarmld. 

IRP Agent creates a new Alarm Information. 
This new Alarm Information is classified as 
active. 


IRP Agent assignes a new notif icationld to this 
notification. 

AIR is mapped to the managedOb jectlnstance 
and the notif icationld of this notification. 

IRP Agent creates a new Alarm Information. This new 
Alarm Information is classified as active. 


notif yChan 
gedAlarm 


IRP Agent uses the same alarmld of the 
related notif yNewAlarm for the 
alarmld of this notification. 

AIR is mapped to this alarmld. 

IRP Agent shall not create a new Alarm 
Information. 


IRP Agent assignes a new notif icationld to this 
notification. 

AIR is mapped to the matching-criteria-attributes 
(defined below) of this notification. The value of this 
set of attributes shall be identical to that of one active 
Alarm Information in the Alarm List. 

IRP Agent shall not create a new Alarm Information. 


notifyClea 
redAlarm 


IRP Agent uses the same alarmld of the 
related notif yNewAlarm for the 
alarmld of this notification. 

AIR is mapped to this alarmld. 

The IRP Agent shall not create a new Alarm 
Information. 

IRP Agent cannot indicate alarm clearing of 
more than one Alarm Information. 


IRP Agent assignes a new notificationld to this 
notification. 

IRP Agent shall not create a new Alarm Information 

AIR is mapped to the matching-criteria-attributes of 
this notification. The value of this set of attributes 
shall be identical to that of one active Alarm 
Information in the Alarm List. Additionally (in the 
same notification), IRP Agent may use 
correlatedNotif ications to carry AIRs of 
other active Alarm Informations whose 
perceivedSeverity is now set to Cleared as well, 
(in accordance to ITU-T Recommendation X.733 [2]) 
or 
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Alarmld is used 


Alarmld is not used 






IRP Agent shall use correlatedNotifications exclusively 
to carry AIRs of active Alarm Informations whose 
perceivedSeverity is now set to Cleared, (in accordance 
with ITU-T Recommendation Q821 [1]). 


notifyAckS 
tateChange 
d 


IRP Agent uses the same alarmld of the 
related notif yNewAlarm for the 
alarmld of this notification. 

AIR is mapped to this alarmld. 

The IRP Agent shall not create a new Alarm 

Information. 

IRP Agent cannot indicate 

Acknowledgement State change of more 

than one Alarm Information. 


IRPAgent assignes a new notif icationld to this 

notification . 

IRPAgent shall not create a new Alarm Information. 

AIR is mapped to the matching-criteria-attributes of 
this notification. The value of this set of attributes 
shall be identical to that of the active Alarm 
Information in the Alarm List. Additionally (in the 
same notification), IRPAgent may use 
correlatedNotifications to carry AIRs of 
other Alarm Informations whose 
Acknowledgement State has changed as well, 
(in accordance to ITU-T Recommendation X.733 [2]) 
or 

IRPAgent shall use correlatedNotifications 
exclusively to carry AIRs of Alarm Informations 
whose Acknowledgement State has changed, 
(in accordance to ITU-T Recommendation Q821 [1]). 



D.1 Matching-Criteria-Attributes 



This clause identifies attributes that are defined in ITU-T Recommendation X.733 [2] as the matching-criteria- 
attributes. The attributes are: 

managedObjectlnstance 

eventType 

- probableCause 

specificProblem, if present 
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Annex E (informative); 
Change history 
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